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The Mechanized Loop Testing (mlt) system is a functional unit of 
the Automated Repair Service Bureau (arsb) which tests and ana- 
lyzes the condition of customer loops. The test results are used to 
verify trouble conditions, assist telephone company personnel in 
providing repair- commitment information to the customer, dispatch 
the appropriate repair craft, and reduce manual testing requirements. 
The mlt system design is distributed over three processing levels of 
the ARSB tree structure (host, front end, controller) to provide the 
necessary record utilization, data processing, loop analysis, and 
control of test equipment. The automatic access, monitoring, and 
testing of loops is performed by specially designed test equipment 
under the direct control of the controller. The mlt system provides a 
set of test series, each designed for specific applications. The test 
series are composed in real time as a function of the equipment 
thought to be present on the loop and the results of tests already 
performed to that point in the test sequence. This adaptive testing 
process has been implemented in hardware and software to provide 
an effective loop-testing system for most applications in the Bell 
System. 

I. INTRODUCTION 

The Mechanized Loop Testing (mlt) system is a major functional 
unit of the Automated Repair Service Bureau (arsb) which automat- 
ically tests and analyzes the condition of customer loops. The tests are 
run at the time the customer reports a trouble, or at any time it is 
necessary to check the condition of the loop. Results of the tests and 
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a detailed loop analysis are generally available within 30 seconds from 
the time the request is initiated. The results are used to provide the 
customer with an accurate assessment of the trouble and to assist in 
establishing an appropriate repair commitment time. In addition, the 
results can be used to efficiently dispatch repair craft and reduce the 
manual testing requirements of the repair operation. 1,2 

The mlt system had its origins in a testing system developed in the 
early 1970s, known as the Line Status Verifier (lsv). 3 This system was 
a threshold-based testing system used by repair-center personnel to 
test a customer line in a rapid, automatic fashion with a simple console 
input request. Tests initiated at the time of customer contact reduced 
substantially subsequent testing by skilled repair personnel. The lsv 
was later integrated with the Loop Maintenance Operations System 
(lmos) so that a test could be initiated from an lmos computer 
terminal and the result made part of the lmos trouble report record. 
While this generation of the arsb provided significant economies, it 
was clear that lmos, by virtue of its comprehensive data base and 
computing power, provided the potential for much more sophisticated 
loop testing. For example, the electrical characteristics of the cus- 
tomer's station, loop, and central office equipment can be derived from 
the lmos data and used to direct tests in an adaptive fashion and 
provide a comprehensive analysis in real time. 4 It was also clear that 
the lsv was not an appropriate testing vehicle since its hard-wired 
logic and threshold testing capabilities were not well-matched to the 
adaptive testing techniques and sophisticated analyses envisioned. 
Hence, a new testing system was necessary to take full advantage of 
the lmos potential and provide additional benefits. 

The development of these expanded testing capabilities occurred in 
two logical post-LSV phases. The first phase, representing the second 
generation of automated testing and known as the Automatic Line 
Verification system, developed the data-communication structure, 
modular physical design, loop access and automatic monitoring capa- 
bilities, computer-driven self-maintenance features, and the basic lmos 
record-utilization techniques. The third-generation testing system, 
known as mlt, added a more comprehensive testing package and 
associated control software which used records more extensively. In 
this paper, we shall discuss only the resulting mlt system. 

The mlt system was intended to significantly reduce but not elimi- 
nate the need for manual testing faculties such as local test desks. 1 
Since manual testing facilities were already present in repair bureaus, 
they could be used as backup testing devices when the mlt system 
experienced temporary outages. In addition, some testing needs, such 
as interactive testing between field and inside repair craft, coin station 
testing, and four- and eight-party line testing seemed to be best left to 
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the manual testing facilities because they were not needed frequently 
and, therefore, mechanizing them did not appear to be cost effective. 
The purpose of this article is to describe the mlt system design. 
Most of the article is devoted to the hardware/software design, but it 
should be noted that an equally important piece of the design, namely, 
the personnel subsystem, is covered, at least sparingly, elsewhere in 
this issue. 5,6 The application of human factors engineering for the mlt 
project by a talented group of psychologists was a significant and 
highly valued contribution to the design and introduction of the 
system. Similarly, we felt it somehow unfair to pay only brief attention 
to other areas of the project including the elaborate self-maintenance 
design of the mlt system, but, again, brevity won out. 

II. BACKGROUND 

A number of requirements and assumptions influenced the design of 
the mlt system and led to an architecture that distributes the mlt 
software functions over three processors. Two of the processors have 
as their primary function the implementation of the lmos system with 
which mlt must interact; the third processor is dedicated to the mlt 
hardware control task. 

2. 1 Operational users 

The mlt system provides operational data to two types of users: 
Repair Service Attendants (rsa), who are in contact with the customer, 
and Repair Service Bureau (rsb) personnel, who analyze the trouble 
and dispatch repair craft. The needs of these two users are similar, but 
not identical. 

The rsa needs a test summary that provides insight to the reported 
problem in a global way. Is a trouble confirmed? Is it a central office 
trouble, a loop trouble, a station trouble? The test has to be performed 
automatically when the trouble report is taken and the results are 
needed promptly so that an appropriate repair commitment can be 
given to the customer. 

The rsb needs complete test results, preferably included with the 
trouble ticket that is automatically produced when the rsa takes the 
trouble report. The rsb also needs the ability to perform tests upon 
demand, sometimes while the repair craft is at the location of the 
trouble. Thus, the rsb needs a list of the available tests, some designed 
to duplicate the comprehensive tests performed when a trouble is 
taken, some tailored to providing data on only a subset of all possible 
problems but at smaller costs of system resources and with shorter 
run times. A total of 11 different series of tests were determined to be 
required. Examples of these limited test series include: ROTARYDIAL 
to test the speed and make-break ratio of a rotary dial, RINGER to 
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simply count the number of ringers, LINECKT to test only the office 
line circuit, and LOOP to test only the loop and on-hook station. 

For both users, it is necessary to interpret the test results in light of 
expected office, line, and station equipment (as gleaned from lmos line 
records) and to be tolerant of incorrect or absent equipment records. 4 
These requirements dictate a close tie to lmos in the initiating of tests 
automatically, in getting test results onto the trouble ticket, and in the 
use of equipment data to define expected test results. 

2.2 Support users 

The mlt system has to provide for two additional types of users 
concerned with support functions. The mlt Administrator is concerned 
with mlt maintenance and the mlt Data Manager is concerned with 
mlt software data initialization and integrity. 

The mlt Administrator requires tools to perform maintenance func- 
tions on the mlt system and to change various system parameters and 
thresholds so that the performance can be tailored to a particular test 
environment. Among the maintenance functions required is the ability 
to calibrate both mlt equipment and test trunks so that systematic 
errors can be subtracted from test results. Other functions provide the 
ability to perform tests designed to verify the general "sanity" of the 
system as a preventative maintenance tool or to perform detailed 
diagnostic testing of circuitry when specific hardware faults are known 
or suspected. Control functions include the ability to change the test- 
result decision thresholds of acceptable levels of foreign voltage and 
loop unbalance and the ability to take specific equipment out of service 
for maintenance. Eleven different transactions or commands were 
identified for maintenance and control functions. 

The mlt Data Manager requires tools to create and maintain the 
various data bases related to mlt. In particular, a data base is used to 
define the equipment configuration of each set of mlt test hardware. 
This data base includes not only the specific quantities of optional 
testing hardware and test trunks that are present, but it also provides 
information concerning which test trunks are used to test which lines, 
the type of switching machine involved (step-by-step, crossbar, ess), 
and the calibration constants for test trunks and mlt testing hardware. 
Some of these data are considered static, that is, seldom changed and 
then only by an appropriate user. The configuration and status data 
are of this type. Other data are considered dynamic, that is, changed 
by software; calibration data are of this type. 

The requirements for the two support users are not served by a 
single software structure. The needs of the Administrator must be met 
by real-time software that can interact with the testing process when 
necessary. 
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Since the mlt files overlap the lmos files, and since similar file 
creation and maintenance problems are solved by lmos via off-line 
processes, the same approach was used for mlt. We will not discuss 
these off-line processes further except to note that one of the consid- 
erations was to design procedures for the creation and maintenance of 
the mlt files to be similar to the procedures used for lmos files. 

2.3 Hardware imposed requirements 

Since the test hardware contained no processing capability, the 
software had to control the hardware on a step-by-step basis. The 
software had to identify the proper hardware resources for a particular 
use, allocate the resources, and cause the equipment to perform a 
particular sequence of steps on a time-critical schedule. This suggested 
that the hardware controller tasks should be on a dedicated machine 
to meet the real-time constraints. 

III. ARCHITECTURE AND FUNCTIONAL DISTRIBUTION 

The mlt system can be thought of as having five fundamental tasks: 
accessing the loop, monitoring the loop to ensure that testing can 
proceed, testing the loop, analyzing the test results, and presenting the 
results in an easily understood fashion. Loops are accessed via "no- 
test" trunks which connect the test system to the switching machine. 
Test trunks are switched onto the desired loop by commands sent 
from the test system to the switching machine. The test system then 
automatically monitors the loop for hazardous and/or busy conditions 
to determine if the testing process can proceed. The access and 
monitoring processes are performed by the Loop Testing Frame (ltf) 
under the direction of the mlt Controller (see Fig. 1). Assuming that 
testing can proceed, the Controller directs the ltf to connect an mlt 
Measurement Module (mmm) to the test trunk (and hence the loop) 
and then commands the mmm to perform a series of tests on the loop 
based on the central office, loop, and station equipment indicated by 
the lmos data base. Tests proceed in an adaptive fashion, taking 
advantage of the increased knowledge of the loop as each test is run. 
The Controller analyzes the test results and decides when to terminate 
the testing process and communicate the results to the front-end 
processor, where they are presented to the user. Typical results might 
look like those shown in Fig. 2. 

The provision of these five basic tasks is accomplished by functions 
distributed throughout the arsb system. 

3.1 ARSB host processor 

The host processor is used by the arsb to maintain historical data 
on closed trouble reports and to maintain extensive line record infor- 
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Fig. 1 — Automated Repair Service Bureau architecture. 



mation on each line. A subset of this line record (called a mini-line 
record) is duplicated in a front-end (fe) processor for fast access by 
rsb craft and to provide the ability to support basic operations when 
the link to the host fails. For mlt, the host is used to scan line records, 
at the time they are established, for the presence of installed equipment 
that could influence testability or test results. These data are formatted 
into a six-byte field for the mini-line record. Also, the host has to 
expand coded test results in real time when they are received from the 
fe into an english narrative in accordance with a predefined algorithm. 

3.2 ARBS front-end processor 

The fe is used by the arsb to process trouble reports and to 
interface with rsa and rsb craft in real time. 8 The lmos software on 
the fe maintains the mini-line record information. It also supports the 
numerous CRT terminals for trouble entry and printers to provide 
trouble tickets — called Basic Output Reports (bor) — to the rsb craft. 

Certain files maintained by the lmos software had to be expanded 
to provide mlt information. For example, the file which provided data 
on the NPA-NNX (area code-exchange code) combinations adminis- 
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tered by the fe had to be enhanced to include an indication of mlt 
testability for the npa-nnx and which mlt equipment could be used. 
The lmos software also had to be expanded to include a provision to 
schedule the mlt process each time a trouble was taken on a line that 
was testable by mlt. The scheduling procedure included the passing 
of the identification of the terminal on which the trouble was taken, 
pertinent information from the mini-line record (such as the six bytes 
of test-affecting data), and information from the npa-nnx file. 

The mlt software on the fe provides several functions: 
(i) It provides an interface to the lmos software so that testing can 
be scheduled when a trouble report is being taken. It also translates 
the mlt bytes into attributes that describe the electrical characteristics 
of the loop, termination, and central office equipment for use by the 
Controller. 

(ii) It provides an interface to rsb craft so that subsequent or 
alternate testing of a line can be performed when requested. 

(Hi) It provides an interface to the mlt administrator so that mlt 
maintenance requests can be serviced. 

(iv) It manages the testing process by controlling the throughput to 
the various mlt Controllers and by preventing lost or delayed requests. 
In doing so, it resolves conflicts between the automatic tests requested 
as a result of trouble entry and tests requested by the rsb or mlt 
Adrninistrator. 

(v) It returns data to the correct requester in a format appropriate 
to the request. 

(vi) It maintains data files unique to mlt needs. For example, one 
file contains the particular ltf configurations served by the mlt 
Controller as well as related calibration data. 

(vii) It stores the Controller software and associated tables, and 
loads the Controllers when the system is initialized or when certain 
trouble conditions arise at the Controllers. 

3.3 MLT Controller 

The mlt Controller is given as large a part of the mlt software task 
as possible. This is done partly to minimize the load on the fe and 
partly to ensure that the lmos software is isolated from mlt software 
changes. The Controller software is responsible for allocating mlt 
hardware resources, controlling the hardware to perform a specific 
test, interpreting test results in light of expected results, adjusting the 
sequence of tests in accordance with expected test results, and deter- 
mining the format of the report. 

Because it was originally expected that the Controller would be 
placed in non-EDP environments, the Controller hardware was kept 
simple. No colocated off-line storage devices or peripherals are used 
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and all software is kept in 256 Kbytes of main memory. The Controller 
software and associated tables are stored in the fe and down-loaded 
over a data link to the Controller at the time of system initialization. 
Although subsequent deployment strategies have tended to centralize 
Controllers in controlled environments, the simplicity of the Controller 
hardware configuration has provided very high reliability and allowed 
low-cost backup schemes. 

The operating system used in the Controller is the same Bell 
Operating System (bos) used in the fe, although only a subset of the 
bos features are provided in the Controller. 7 In particular, BOS provides 
a software driver for interfacing to multiple loop testing frames. The 
driver links the testing hardware and application software in real time 
so that data can be sent to and from an ltf in a serial format. 

Similarly, communication between the fe and Controller is managed 
by the Communication Control Manager (ccm) 8 software on the fe 
and a subset of ccm, known as mltccm, on the Controller. The 
communication protocol used was chosen to be a subset of the IBM 
bisync protocol used between the host and fe processors to avoid the 
creation of a new protocol. 

3.4 Loop Testing Frame 

The Loop Testing Frame (ltf), equipped with mlt measurement 
modules, carries out the access, monitoring, and test functions under 
the command of the Controller (Figs. 3 and 4). A data link between 
the Controller and the Communication Control Circuit (ccc) of the 
ltf provides the data communication facility. No-test trunks between 
the Trunk Access Switch (tas) of the ltf and the switching machines 
provide the metallic test path to the loop. Commands from the Con- 
troller are decoded by the ccc, and control information is passed to 
the appropriate ltf subsystem. Similarly, data from each subsystem 
are passed to the ccc which appends the output address and transmits 
the data to the Controller for interpretation. 

The LTF was envisioned as an area-based test unit, i.e., a single 
system deployed on a wide-area basis and serving many central office 
switching machines, to share the common testing facilities over as 
many lines as possible. Since interactive tests were to be relegated to 
existing manual testing facilities, the most lengthy test series run by 
mlt on a loop was estimated to take less than 15 seconds of actual 
testing time. Hence, an area-based, high-usage, low-holding-time sys- 
tem was conceived. The ltf was designed to serve up to a maximum 
of 98 no-test trunks with nine test ports (or nine simultaneous access/ 
monitor/test operations) for a concentration ratio of about 11:1. Traffic 
estimates suggested that this was adequate to cover anticipated testing 
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Fig. 3 — Loop Testing Frame equipped with four mlt measurement modules. 

traffic for more than 250,000 lines, which was expected to at least equal 
the capacity of the Controller. 

The ltf serving area was determined not only by the demographics 
but also by the physical limitations of metallic testing. Beyond about 
3,000 ohms of loop resistance or 100,000 feet if 19-gauge cable is used, 
it becomes increasingly difficult to differentiate between open loops 
and loops terminated with station set ringers or the equivalent. Since 
differentiation between open and terminated loops is essential, 3,000 
ohms essentially defined the ltf serving area. This was a reasonable 
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Fig. 4 — Schematic of loop testing frame equipped with an mlt measurement module. 

limitation since the signaling range for most no-test trunks is in the 
neighborhood of 1,500 ohms, and most loops are also less than 1,500 
ohms. Hence, the ltf serving area accommodated most loop lengths 
with maximum-length no-test trunks, thereby supporting rather neatly 
the area-based testing concept. 

3.5 Configuration 

Each fe can serve up to 16 Controllers. Each Controller can serve 
up to six ltfs with no more than 40 nnxs or 120 no-test trunks. The 
Controller limits are primarily based on table limitations, but a ratio 
of about three no-test trunks per nnx has proven to be the proper 
average for mlt testing traffic. The ltfs are connected by data links 
to the Controller and therefore can be located in central offices in a 
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pattern that ensures optimum coverage relative to the 3,000-ohm ltf 
serving area. 

IV. SOFTWARE DESIGN 

In this section the design of the software that executes on the 
Controller is described in some detail. First, we define three terms: 

(i) ltf Communication — The protocol used to communicate be- 
tween the Controller and the ltf was referred to briefly in an earlier 
section. In particular, a given transmission "packet" can be a variable 
number of words in length. Each word consists of two parts, an address 
and data. In the direction from the Controller to the ltf, the protocol 
includes a bit to indicate if the word is the last one of a "packet." One 
or more packets of data interchange may be necessary to set up or 
perform the most basic hardware action. In the direction to the 
Controller, the data is completely asynchronous. The Controller must 
be capable of accepting data at the peak rate determined by the serial 
line speed and must buffer these data until they can be processed. 

(ii) Test Sequence — A set of hardware/software interactions that 
accomplish a single characterization, such as a count of ringers, a dc or 
ac Thevenin equivalent circuit, etc. Twenty-three separate test se- 
quences are provided by mlt. 4 

(Hi) Test Series — A set of test sequences that provide a complete 
characterization of a line. Obviously, the requested type of series 
influences the specific sequences that are used; for example, the 
RINGER series (designed to be a high-speed, low-cost test to count 
ringers) does not include sequences that make measurements on the 
switching office line circuits. But, the particular sequences that are 
used — even the order of the sequences — can be influenced both by the 
results of previous test sequences and the expected results from ex- 
amination of the records. 4 

The operating system and mlt software processes are organized as 
depicted in Fig. 5. Their functions are described below. 

The Driver, which is part of the operating system, interfaces with 
the Frame Communication Manager (fcm) and to the hardware cir- 
cuitry that implements the serial interface to the ltfs. The driver is 
provided data for transmission that has been formatted into the proper 
protocol. It collects data from the various hardware circuits on a 
character-interrupt basis and inserts the data into buffers that are 
emptied by the fcm process when cpu time permits. The driver serves 
the data distribution and collection function to the ltfs and permits 
the mlt software to be largely unaware of the existence of more than 
one ltf. 

The Frame Communication Manager interfaces to the driver and 
to the tsp and sup (supervisor) processes that contain application 
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Fig. 5— mlt controller software structure. 

software. The fcm process performs a service that is similar to the 
ccm process discussed earlier. The fcm can be thought of as an 
extension of the operating system in that it provides a virtual machine 
environment for the application software. With fcm, the processes 
that control a single test series have no knowledge of the existence of 
other processes executing other tests concurrently. The fcm accepts 
primitive commands to be sent to the ltfs, implements the protocol, 
collects data and sends it to the proper user process, and generally 
gives each user process the appearance of being the only process 
requesting data from the ltf. 

The fcm process is created at initialization time, and it never 
terminates. It is awakened by either of two types of events. User 
processes, knowing that they have data to send to the ltf, can awaken 
the fcm process through bos via a "notify" mechanism, fcm can also 
be awakened by an alarm mechanism, also managed by bos. Each time 
that fcm is awakened, it checks whether data are available in the 
buffers that are filled by the driver. If so, it collects the data into 
complete messages and provides them to the user processes by writing 
the data into a previously agreed upon area of the test buffer. Normally, 
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the user process is waiting for either these data or for a timeout time. 
The fcm, seeing that the data are available (or that the time-out 
occurred), awakens the user process that owns the test buffer (again 
via bos). Also, each time that the fcm is awakened, it searches through 
the test buffers to see if any process has data ready to be sent to an 
ltf. Data to be sent are left in a previously agreed upon area in the 
test buffer and a ready flag is set in the buffer. Finally, fcm cancels 
any previous alarm and sets a new alarm call to be awakened within 
a short time. 

The selection of the sleep time was an interesting problem. At one 
extreme, fcm could set the alarm for such a short time that little 
processing resources are available to other processes. At the other 
extreme, fcm could set the alarm for such a long time that the data 
collected by the driver would be utilized too slowly and would overflow 
the existing buffers. An aspect of this design is that the alarm feature 
is used less frequently when the Controller is heavily loaded with tests 
since the notify mechanism awakens fcm more frequently. The alarm 
feature is required to collect data when only one test is underway in 
the Controller. Under this condition, it is desirable not to wait too long 
before looking for returned data as this would unnecessarily delay the 
testing process. The optimum sleep time was determined experimen- 
tally to be in the range of 100 milliseconds. 

The Test Supervisor (tsp) process is a child process to the Series 
Control (ser) and implements the test sequences. That is, ser, when 
it first determines that testing is required, creates a child tsp process 
(via a call to bos) and passes to tsp the address of the test buffer that 
is owned by ser. At this point, the child tsp process inherits the test 
buffer. When a requested test sequence is completed, tsp notifies its 
parent process and asks to have its execution suspended. Each time 
that ser wants another test sequence executed, the name of the 
sequence is placed in an agreed-upon place in the test buffer and tsp 
is notified. Each time that tsp performs a sequence, it puts the 
accumulated data in the test buffer in two areas. Binary results (yes- 
no) are indicated by setting bits in a bit-field.* Analog results are 
placed in the test buffer in a format appropriate to the result. For 
example, voltages or currents are kept in floating-point format, whereas 
the number of ringers is stored as an integer. The tsp is finally 
terminated by ser when no additional testing is required. 

The ser process interfaces to tsp and sup, and implements the test 
series, ser is a child process to sup, but sup terminates after ser is 
created and gains control of the test buffer. (In principle, it would not 



* Examples of binary results are: bit 66, if set, means that the dc signature looks like 
a pbx; bit 25, if set, means BUSY SPEECH; etc. 
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be necessary for sup to terminate after creating process ser, but the 
arrangement described is used to minimize the number of processes 
that must be active simultaneously, since each active process entails 
additional overhead.) 

The ser creates child process tsp; ser and tsp take turns being 
active as discussed above. When ser has implemented enough of a 
test series to determine that "early" results to the rsa are required, 
process sup is scheduled to send the results to the fe. The ser waits 
for sup to terminate and then continues to the point that testing is 
completed. Then ser terminates the child process tsp, schedules 
process sup, waits for sup to gain control of the buffer, and then 
terminates. 

The sup process interfaces to mltccm and to ser. sup provides 
general control over the test function, gains access to the line under 
test, and formats reports to the fe. 

V. THE TESTING HARDWARE DESIGN 

As previously mentioned, the testing hardware (Figs. 3 and 4) can 
be divided into two major subsystems: the ltf and the mmm. The ltf 
controls access to customer loops via no-test trunks and determines 
the busy/idle status of the loop. The mmm performs tests on idle loops 
for fault characterization. 

Two interfaces to the ltf exist. The ccc provides the interface to 
the Controller. The tas provides the interface to customer loops via 
no-test trunks to the central office switch. 

The ccc serves as a multiplexer and demultiplexer for data to and 
from the Controller. Transmission is via a four-wire circuit using full 
duplex asynchronous serial data rates of 1200 or 2400 baud. The 1200- 
baud rate uses 202-type data sets for installations where the Controller 
and ltf are separated by more than 1500 feet. Within 1500 ft the 
transmisssion can be set to 2400 baud using optically isolated current 
loops. 

Data from the Controller consist of an address field and a control- 
signal field. The ccc decodes the address and passes the control signal 
to the appropriate subassembly of the ltf/mmm. Data from each 
subassembly are digitally encoded by the subassembly and passed to 
the ccc which adds the output address to the data and transmits them 
to the Controller for interpretation. 

The Access Switch Controller (asc) receives control signals from the 
Controller via the ccc and provides signals to the tas and the Equip- 
ment Access Switch (eas). These signals select, hold, and release the 
crosspoints of these two switching matrices. 

The tas serves as a concentrator and permits the connection of up 
to 98 no-test trunks to one of nine test ports. The test ports are routed 
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through the Supervisor and Control Circuit (sec) to the eas. The eas 
permits the connection of any test port to either a dialer, busy detector, 

or MMM. 

The sec provides the control and monitor functions required to 
access a customer loop via a no-test trunk. Loop access includes the 
functions of sharing trunks with the local test desk, sleeve-lead super- 
vision, ring-tip supervision, dialing, and busy detection. In addition to 
access, the circuit provides for hazardous potential detection and 
interruption of the test path to prevent equipment damage. Dialing 
circuits are provided for both dial pulse (dp) or multifrequency (mf) 
signaling. 

Once the loop has been dialed and the sleeve lead manipulated to 
effect a cut through to the loop, a busy test is made. The busy test 
provides outputs of idle, switching-machine overflow, dc busy (battery 
ring to tip), and speech busy. If the loop is idle, the test port, and 
therefore the loop under test, is transferred to the mmm for testing. If 
the loop is other than idle, access to the loop is dropped and the loop 
status is reported to the Controller. 

5.1 MLT measurement module description and operation 

The mmm provides the loop-testing capability for the mlt hardware 
and consists of three major sections: the Source and Output Interface 
(soi), the Test Package (tp) and the Test Package Auxiliary (tpa). 

The soi performs a service function for the tps and tpa by providing 
clock frequencies for the digital circuits, precision leveled frequencies 
for analog sources, and a precision dc reference for analog sources. The 
soi also contains output encoding circuits for the analog measured 
voltages generated by tps and the tpa during loop tests. The soi pools 
the tps and tpa for outputs and, if present, they are connected to the 
soi encoding circuits. The encoding circuits include a 12-bit analog-to- 
digital (a/d) converter, an auto ranging amplifier required to present 
properly leveled signals to the a/d, and a polarity sensor. The digitally 
encoded output measurement is temporarily stored in a RAM buffer 
along with its unique output address. The address is determined by 
which tp or tpa circuits are being serviced by the a/d. Upon receipt 
of a poll, the output data is passed to the ccc for transmission to the 
Controller. 

The soi also contains sources and terminations which are used to 
isolate hardware failures to particular circuit packs. This capability is 
controlled by the Sanity and Diagnostic software modules in the 
Controller (Section 2.3). 

The tp (Fig. 6) is a multipurpose test circuit which is configured for 
a particular test by commands from the Controller. The tp is the heart 
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of the mlt hardware. It can be divided into a test section, through 
which all analog test signals flow, and a control section. 

The test section has as its input, the tip and ring of the loop under 
test. The output of the test section is a dc voltage proportional to the 
quantity being measured. The dc voltages are passed to the soi for 
processing as previously described. 

The test section has two essentially identical measurement channels 
which allow simultaneous testing of both tip and ring conductors. Each 
measurement channel consists of a number of analog signal-processing 
blocks which can be connected in various combinations, via switches, 
to set up the desired measuring circuit. 

The analog signal processing blocks can be separated into four main 
categories: sensors, filters, detectors, and miscellaneous. The tp em- 
ploys several types of sensors for the tests it performs. 

The Active Current Sensor (acs) senses the current flowing in the 
conductor under test. The dc and ac voltages ranging from to 80 
volts can be applied to tip and/or ring through the ACS, and the 
resultant current measured to give a measure of circuit impedance. 
Other sensors are provided for detecting foreign voltage, measuring 
the longitudinal balance of the loop, and identifying Receiver-Off- 
Hook (roh) conditions. 

The test package filters provide for rejection of 60-Hz noise by a 60- 
Hz band-elimination filter, separation of ac and dc signals by Bessel 
high-pass and low-pass filters, and selection of individual test frequen- 
cies by a bank of bandpass filters. 

Three types of signal detectors are incorporated into the design. The 
phase detector produces a pair of voltages that are proportional to the 
real and imaginary components of the impedance at 24 Hz of the 
circuit under test. The rms detector produces a dc voltage output 
equal to the true rms of any ac signal or noise appearing at its input. 
The precision detector produces an output that is the average value of 
the ac signal appearing at its input. 

Miscellaneous tp circuits are the Source Select Amplifer and the 
Phase Null circuit. The Source Select Amplifier selects the ac and/or 
dc voltage to be applied for a test and sets their levels dependent upon 
control signals received from the Controller. The phase null circuits 
automatically compensate for phase shift through the analog signal 
processing blocks and null the output of the phase detector during 
periods of idle time (no-test request). 

Sanity Reference points (sr points in Fig. 6) are provided for signal 
injection or passive termination connection by the soi during self- 
check (known as Sanity and Diagnostics) testing. 

The control section of the tp receives instructions from the Con- 
troller via the ccc, operates the test package switches which control 
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test configuration, times the set up and progress of all tests, and 
controls the sequencing of connection of the outputs to the soi encod- 
ing circuits. 

The third major section of the mmm is the tpa. Unlike the tp, the 
tpa is not a configurable test circuit. It is designed to perform specific 
tests which, due to their length, would be an inefficient use of the tp 
resources. Two test functions are provided: Rotary Dial Analyzer and 
Dial Tone Analyzer. 

The Rotary Dial Analyzer contains a signal-conditioning circuit 
which performs dc restoration and signal clamping required to inter- 
face with logic measuring circuits. The dial pulses gate a clock signal 
to two digital counter circuits. The output registers of the two counters 
are used to determine the number of dial pulses received and the speed 
and percent break of the rotary dial being tested. 

The Dial Tone Analyzer presents a constant-current sink for the 
switching-machine dial-tone generator. This sink provides a 20-mA 
load to the generator regardless of the length of the no-test trunk, 
thereby simulating worst-case loop conditions. The sink can be confi- 
gured for loop-start, ground start, or ground start reverse line circuits. 

The constant-current sink is followed by a band-pass filter to sepa- 
rate the dial-tone frequencies from noise signals. A precision detector 
converts the received dial-tone voltage to a dc level compatible with 
the encoding circuits of the soi. 

5.2 Teat capabilities 

A brief description of the test capabilities follows: 

DC Thevenin—This test measures parameters required to form a 
three-terminal dc Thevenin equivalent circuit looking into tip, ring, 
and ground. It identifies resistive faults, dc foreign voltage, crosses to 
working pairs, ground start pbx signatures, central office line-circuit 
faults, and lines on intercept. 

Short Circuit Current — This test measures the short circuit noise 
current tip to ground and ring to ground. 

Three Terminal Admittance — This test uses the phase detector in 
the tp to determine the real (resistive) and imaginary (capacitive) 
components at 24 Hz of the loop between tip, ring, and ground. This 
measurement is used to determine the length of no-test trunks, the 
length of loops, to detect pots ringers, to identify whether a pair is 
open on tip, ring, or both sides and whether the open is in or out of the 
central office, and to measure the distance to the open if it is out of the 
central office. 

Open Circuit ac and dc Foreign Voltage— This test measures the 
open circuit dc foreign voltage and the ac voltage appearing tip to 
ground and ring to ground. 
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Receiver-Off-Hook (ROH) — This test uses the nonlinearity of the 
off-hook station set to discriminate between a tip-to-ring resistive 
short and an off-hook set. 

Thermistor Heating — This test provides a means of detecting the 
presence of thermistors in the alerting circuits of pbxs and Key 
Telephone Sets by detecting the change in the real part of the admit- 
tance at 24 Hz as a voltage is applied by the tp. 

Ringer Counting — This test provides a means of counting the num- 
ber of ringers connected tip-to-ring, tip-to-ground, or ring-to-ground. 
Cable capacitance is differentiated from ringer capacitance by an 
algorithm that compares loop admittance at several frequencies. 

Longitudinal Balance — This test provides measurements for deter- 
mining loop balance to 65 dB at 200 and 800 Hz. 

Soak — This test measures the time variance of a resistive fault with 
an applied dc voltage. 

Dial Tone Analyzer — This test measures whether dial tone can be 
drawn and broken. It indicates whether the dial tone is drawn normally 
(within 3 seconds) or slowly (3 to 6 seconds). 

Rotary Dial Analyzer — This test counts the number of pulses from 
a rotary dial, and measures the dial speed and percent break. 

5.3 Calibration 

To assist in improving measurement accuracy, the ability is provided 
to perform no-test trunk calibration. Dedicated telephone numbers, 
which are open circuited on the main distributing frame, are accessed 
and tested to determine whether trunk faults exist and to determine 
the length of the trunk. The length measurements are used in making 
decisions on the locations of open faults. 

Component aging may cause a degradation of the measurement 
accuracy. To compensate for this effect, the tp is designed to permit 
measurement of critical ac and dc gains and offset voltages. These 
parameters are stored in the Controller and used in the associated 
software test algorithms. The calibration is initiated via a system 
request at the fe. 

As previously mentioned, test nodes are provided in the tp and tpa 
where sources and/or passive terminations in the soi can be applied, 
under software control, to isolate component failures to particular 
circuit packs. The soi also cotains circuits that permit testing of the 
A/D encoding circuits and the RAM buffer. 

5.4 Packaging 

The ltf is mounted in a standard 7-ft UNIFRAME consisting of 
dual 38-in. bays (Fig. 3). The design is modular and connectorized, 
which permits growth from a minimum to a maximum system by the 
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addition of circuit packs of plug-in subassemblies. The minimum ltf/ 
mmm serves up to approximately 15,000 lines and the maximum ltf/ 
mmm serves approximately 250,000 lines. 

The minimum ltf/mmm consists of one tas that can accommodate 
up to 18 no-test trunks, circuit packs to activate two test ports, either 
two dial pulse or two multifrequency dialers, one Test Package (tp), 
and one Dial Tone Analyzer. The maximum ltf/mmm consists of four 
tass to accommodate 98 no-test trunks, circuit packs for nine test 
ports, two dial pulse and two multifrequency dialers, four tps, two Dial 
Tone Analyzers, and one Rotary Dial Analyzer. 

VI. CONCLUSION 

The mlt system had its field trial in Nashville, Tennessee, beginning 
in late April 1978. By the end of 1978, four Bell Operating Companies 
had implemented standard mlt systems produced by Western Electric 
and, by the end of 1979 thirteen companies were using mlt. Conversion 
to mlt systems during 1979 and 1980 was running at almost 2 million 
lines per month. 

The economic and operational success of the mlt system is docu- 
mented elsewhere in this issue. 2 At this writing, Southern Bell Tele- 
phone and Telegraph Company has installed more mlt systems (197 
ltfs and 59 Controllers by the end of 1980) than any other Bell 
Operating Company. In Southern Bell, the operational availability of 
the ltfs and associated mmms is running at 99.7 percent, while the 
overall availability (Controllers, data links, ltfs, etc.) of the system is 
currently 99.3 percent. 
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